In modern computer systems it is conventional to provide a central processor unit having a resident on board system (ROS), typically in firmware such as ROM 21 of FIG. 1 which starts the basic machine's boot procedure, and one or more associated non-volatile mass storage devices such as a direct access storage device (DASD).
Due to the possibility of power failures, malfunction of one or more system components which may, for example, give rise to data corruption, and the like, such information systems further typically provide for various forms of system backup procedures. These procedures create and store, on the non-volatile storage such as DASD (10-14, FIG. 1) the necessary files such as the bootstrap image 40 of FIG. 3 which, when read from the DASD and executed as a result of execution of the IPL control programs typically stored in DASD, enables the system to resume a prior state. Initially hardware bootstrap code or ROS in ROM is typically executed to facilitate subsequent reading of the bootstrap image on media. A representative example of such a system providing general background on the problems associated therewith may be seen in U.S. Pat. No. 4,623,963 entitled "Device Independent Data Transfer".
One problem with these systems is that the IPL typically may require that the bootstrap be written and read from the storage device in a fixed format. Because the IPL code may itself be fixed in ROM hardware, such ROS code itself cannot easily and practically be updated to allow for reading the bootstrap image off the media in formats other than the original one provided for in the ROS code stored in ROM. One reason giving rise to data storage media formats in which the bootstrap IPL code is stored differing from that required by the ROS is technology improvements in the data storage media.
A serious consequence of the foregoing results when the stored bootstrap IPL code on media must be in a format compatible with the ROS code in ROM. Other software, such as system files, catalogs, applications, and data, as well as future bootstrap images are thereby forced to remain at the fixed format dictated by the ROS format. The aforementioned technology improvements in the storage media cannot therefore be utilized, as the media will be required to use the lower capacity format dictated by the ROM.
An example will serve to illustrate the problem. In a typical current system backup program, the mass storage device may be implemented in the form of a tape drive configured to 512 bytes-per-block during creation of the system backup. This requirement, in turn, was dictated by the fact that the ROS of the computer system was written to interface to devices in the 512 bytes-per-block format. Obviously if the tape was written in any format other than the 512 bytes-per-block format, then, the ROS could not understand the data held in the tape such as the IPL bootstrap image necessary to fully bring the system up.
Such tape drives typically store data on 8 millimeter tape which may hold two million blocks, each such block in turn being capable of holding a total of 1,024 bytes of data. Thus, a typical tape may have a maximum capacity of greater than two gigabytes of data storage. However, because the ROS requires a format having a capacity of half that of the tape drive, e.g. it requires that the software to generate the IPL stored on media be written in the 512 bytes per block format, it stands to reason that only half of each tape block is written to with real data, with the rest of each block being left blank.
This graphically illustrates one of the serious problems associated with present systems. The system backup program can accordingly write one gigabyte of data per eight millimeter tape notwithstanding that the tape and tape drive have a capacity of two gigabytes of data storage. This results in great inefficiencies in terms of time and money. Specifically, the time taken to create the system backup is effectively doubled. Moreover, the cost of extra tapes adds to the user's maintenance cost. Notwithstanding this, it is nevertheless too expensive and impractical to change ROS chips in the field to allow larger bytes-per-block densities to be written to and read from the storage technology (in this case a tape drive) which continues to exhibit extremely significant rapid continual advances in densities and formats.
One approach currently used in an effort to solve the problem is to provide for two separate media. The bootstrap image is held on one media which is utilized to boot the computer system. Once the system is up and running, yet another piece of storage media is substituted. The computer operator changes the configuration of the storage device so that the storage media is used in an improved storage mode for software other than the bootstrap image necessary to enable the system to get up and running. Once the operator has thus changed the storage device configuration, the balance of the software is read by the system and restored in that new mode.
Such an approach has at least two major drawbacks. The most obvious is that two pieces of storage media are required for every data store. Moreover, the user must be aware of what value the device must be changed to in order to read the secondary storage media.
Yet a second attempt to solve the problem was to have the bootstrap image and the other software to be delivered to the system residing on the same media but written in different modes, e.g. the bootstrap image would be in the mode required by the firmware whereas the balance of the software would be in a different and presumably higher capacity format. After the IPL control reads in the bootstrap image to the computer system, the system would thereafter halt and wait for operator intervention. The operator must then change the device parameters to match the software, manipulate the storage media so that it was ready to restore its information, and thence issue the restoration command.
Again there are serious drawbacks with this approach. First, the user must be aware of the new value for the device. Still further, the user must also have enough knowledge of the system to position the storage media so that the correct record is read.
Yet another approach was attempted in the art to solve the foregoing problems. In this third method, both the bootstrap image and the main software to be delivered were stored on the same media and written in the same mode. After the IPL code brought the system up, the restoration automatically would position the storage media to the record containing the software to be delivered. Then, that image would be restored onto the machine with no changes in the devices mode. However, because the ROS dictated the mode as previously described, storage of the main storage beyond the bootstrap image was obviously limited to the lower density format dictated by the ROS mode.
From the foregoing, it will be appreciated as storage devices improve, it was highly desired that the concomitant amount of data archived to media could be improved without the need to change the ROM hardware.
It was yet another object of the invention to provide for system backup wherein the need for operator intervention in controlling device attributes was obviated.
Still another object of the invention was to enable the system operator to avoid having to know what values the software itself required for restoration.
Still another object of the invention was to permit the operator, at the time the backup and other software images were created on the storage media, to control the density with which the image was written to the media.
Still a further object of the invention was to significantly reduce the time required in archiving and restoring the system as higher storage densities became available and used for the software image.
These and other objects are provided by the invention which may be understood in greater detail with reference to the figures wherein: